AC-0(0- 15:2 


Investigation  of  Interoperability 
Mechanisms  Betv/een  C3I  Projects: 
The  Strategic  Client  Demonstrator 

B.  McClure 


19971007  192 


APPROVED  FOR  PUBLIC  RELEASE 


©  Commonwealth  of  Australia 


DEFENCE  SCIENCE  AND  TECHNOLOGY  ORGANISATION 


Investigation  of  Interoperability  Mechanisms 
Between  C3I  Projects: 

The  Strategic  Client  Demonstrator 


B. McClure 

Information  Technology  Division 
Electronics  and  Surveillance  Research  Laboratory 

DSTO-CR-0038 


ABSTRACT 

This  report  describes  the  demonstration  of  several  potentially  useful  concepts  in 
the  Command  and  Control  Information  System  Interoperability  Laboratory 
(CCISIL).  These  go  some  way  toward  addressing  the  problem  of  ADF  staff 
requiring  access  to  more  than  one  system.  A  new  potential  capability  is 
demonstrated  to  achieve  a  moderate  level  of  integration  between  AUSTACSS 
and  JCSE  for  sites  that  are  running  both  systems.  This  work  reveals  some 
problems  that  can  occur  as  a  result  of  using  remote  execution,  particularly  for 
applications  with  high  levels  of  customisation  or  integration  as  is  the  case  for 
the  current  build  of  AUSTACSS.  An  ability  to  use  either  AUSTACSS  or  JCSE 
from  a  commercial  PC  X  emulation  package  is  demonstrated,  and  some 
performance  measures  are  discussed. 
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Investigation  of  Interoperability  Mechanisms 
Between  C3I  Projects: 

The  Strategic  Client  Demonstrator 


Executive  Summary 

The  Strategic  Client  Demonstrator  concept  seeks  to  address  a  major  problem 
facing  users  of  current  C3I  related  systems:  that  the  user  often  requires  access  to 
more  than  one  system,  and,  therefore,  may  need  to  accommodate  more  than 
one  computer  on  his  or  her  desk.  This  situation  causes  waste  of  resources  and 
is  less  than  optimal  from  a  useablility  viewpoint. 

The  first  stage  of  this  project  aimed  to  demonstrate  the  feasibility  of  accessing 
multiple  systems  (such  as  JP2030  and  AUSTACSS)  from  a  single  UNIX 
workstation.  Phase  one  work  was  initially  intended  as  a  tool  to  gain  user 
requirements  for  interoperability  between  the  JP2030  and  AUSTACSS  systems. 
Those  requirements  were  to  feed  into  a  subsequent  phase,  to  demonstrate  a 
useful  level  of  application  interoperability  between  the  two  systems. 

This  report  describes  the  demonstration  of  several  potentially  useful  concepts  in 
the  Command  and  Control  Information  System  Interoperability  Laboratory 
(CCISIL).  These  go  some  way  toward  addressing  the  problem  of  ADF  staff 
requiring  more  than  one  computer  on  their  desk.  A  new  capability  is 
demonstrated  to  achieve  a  moderate  level  of  integration  between  AUSTACSS 
and  JCSE  for  sites  that  are  running  both  systems.  This  work  reveals  some 
problems  that  can  occur  as  a  result  of  using  remote  execution,  particularly  for 
applications  with  high  levels  of  customisation  or  integration  as  is  the  case  for 
the  current  build  of  AUSTACSS.  The  Strategic  Client  Demonstrator  is  a  stop 
gap  measure.  It  does  not  display  a  high  level  of  application  interoperability, 
nor  is  it  optimal  in  terms  of  useability.  From  the  users  perspective,  there  should 
be  one  integrated  system  that  contains  the  correct  and  up  to  date  information. 

Another,  related  part  of  this  research  is  to  demonstrate  access  to  the  JCSE  and 
AUSTACSS  software  from  a  Windows  95  based  X  emulation  program.  An 
ability  to  use  either  AUSTACSS  or  JCSE  from  a  commercial  PC  X  emulation 
package  is  demonstrated.  Performance  measurements  indicate  that  both 
remote  execution  and  PC  emulation  provide  reasonable  response  times, 
provided  that  the  network  is  not  overloaded.  Further,  an  analysis  of  the  CPU 
utilisation  of  the  host  during  a  high  activity  period  would  indicate  that  there  is 
potential  for  several  PCs  to  run  off  a  server,  and  possibly  more  from  a  suitably 
configured  server. 
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1.  Introduction 


The  Strategic  Client  Demonstrator  concept  seeks  to  address  a  major  problem 
facing  users  of  current  C3I  related  systems:  that  the  user  often  requires  access 
to  more  than  one  system,  and,  therefore,  may  need  to  accommodate  more 
than  one  computer  on  his  or  her  desk.  This  situation  causes  waste  of 
resources  and  is  less  than  optimal  from  a  useablility  viewpoint. 

The  first  stage  of  this  project  aimed  to  demonstrate  the  feasibility  of  accessing 
multiple  systems  (such  as  JP2030  and  AUSTACSS)  from  a  single  UNIX 
workstation.  Another  part  of  this  research  is  to  demonstrate  access  to  the 
JCSE  and  AUSTACSS  software  from  a  Windows95  based  X  emulation 
program.  Phase  one  work  was  initially  intended  as  a  tool  to  gain  user 
requirements  for  interoperability  between  the  JP2030  and  AUSTACSS 
systems.  Those  requirements  were  to  feed  into  a  subsequent  phase,  to 
demonstrate  a  useful  level  of  application  interoperability  between  the  two 
systems. 

The  Strategic  Client  Demonstrator  is  a  stop  gap  measure.  It  does  not  display 
a  high  level  of  application  interoperability,  nor  is  it  optimal  in  terms  of 
useability.  From  the  users  perspective,  there  should  be  one  integrated  system 
that  contains  the  correct  and  up  to  date  information. 

This  work  is  being  carried  out  under  task  ADF  96/182  'CCISIL  Research'[l], 
and  is  in  addition  to  the  ongoing  work  of  verifiying  and  documenting  the 
baseline  interoperability  delivered  by  the  two  Projects  [2]. 

Following  the  26*  September  1996  meeting  with  the  task's  sponsor,  the 
direction  of  this  work  was  modified.  The  first  phase  developed  the  ability  to 
demonstrate  access  to  AUSTACSS  and  JP2030  from  a  single  UNIX 
workstation,  but  the  later  work  is  targeted  toward  investigating  the  ability  to 
port  one  or  both  of  the  project  systems  to  a  different  platform.  The  aim  of  the 
second  phase  is  to  demonstrate  AUSTACSS  and  JP2030  running  on  the  same 
hardware. 

It  should  be  noted  that  the  work  reported  here  was  performed  using 
AUSTACSS  Build  2/3  release  1.1  and  JCSE  version  2.0.2a.  Unless  otherwise 
stated,  all  comments  refer  to  these  versions  of  the  software. 
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2.  Remote  Execution  of  Project  Software 


2.1  CCISIL  Setup 


During  the  work  described  in  this  report,  the  AUSTACSS  and  JP2030  systems 
were  installed  in  the  CCISIL  on  a  common  ethernet  LAN,  see  Figure  1. 


Figure  1:  CCISIL  Setup  for  remote  execution  demonstration 


The  two  systems  were  configured  on  different  subnets.  This  was  not  a 
problem  because  routeing  software  was  running  on  the  AUSTACSS  server. 


2.2  Changes  required 


In  order  to  demonstrate  access  to  both  systems,  it  was  necessary  to  enable  a 
user  to  remotely  log  into  the  other  system.  For  example,  an  AUSTACSS  user 
can  display  both  the  AUSTACSS  Battlemap  and  the  JP2030  Picture  Manager 
at  the  same  time.  While  in  principle  this  is  a  trivial  task,  in  practice  there  were 
a  number  of  complicating  factors: 
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1)  The  AUSTACSS  users  do  not  have  access  to  a  command  line  (xterm)  to 
perform  remote  logins. 

2)  There  is  resource  contention  when  displaying  non-project  software  on  the 
workstation. 

3)  Many  environment  variables  need  to  be  initialised  before  the  remote 
software  can  be  executed. 

Solving  these  problems  without  comprehensive  documentation  takes  time. 

For  the  purpose  of  investigating  and  demonstrating  the  concept  the  following 

applications  were  made  available  to  users: 

AUSTACSS  users  could  run  the  following  JCSE  applications 

•  Applix  word. 

•  Picture  Manager 

•  Message  Queue  Manager 

•  Lotus  Notes 


JCSE  users  could  run  the  following  AUSTACSS  applications 

•  Applix  word 

•  Battlemap 

•  Message  History 

•  Filer 

In  most  cases,  in  both  JCSE  and  AUSTACSS,  these  applications  are  started 
from  the  CDE/HP  VUE  menu  bar.  The  look  of  this  menu  bar  is  defined  by 
several  scripts  that  reside  in  the  filesystem.  In  order  to  provide  a  simple 
method  for  the  user  to  execute  the  remote  software,  these  scripts  were 
modified.  A  control  with  several  icons  was  added  to  the  menu  bar  so  that  the 
user  could  simply  click  the  icon  and  the  remote  software  would  be  started 
and  displayed.  As  stated  above,  this  script  logs  in  to  the  remote  system,  sets 
many  environment  variables  and  then  runs  the  required  application.  In  order 
to  prevent  passwords  from  being  stored  in  the  scripts,  the  user  account 
SOIOPS  in  AUSTACSS  and  a  user  account  called  ccisill  in  JCSE  were  set  up 
so  that  a  password  was  not  required  to  log  from  one  to  the  other. 

Note  that  this  approach  does  not  require  the  user  to  log  in  to  the  remote 
computer  using  an  xterminal  and  so  problem  1)  above  is  avoided. 


2.3  Results  of  AUSTACSS  to  JCSE  remote  execution 


Eigure  2  depicts  an  example  session  where  an  AUSTACSS  user  has  access  to 
both  the  AUSTACSS  Battlemap  and  the  JCSE  Picture  Manager.  In  this  case 
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the  user  has  been  able  to  cut  graphics  from  both  mapping  systems  into  a 
single  document. 


Fie  Edit  View  Insert  Attributes  Format  Table  UtIHes 


iFfltCljilJll  Normal 


ProjfctisD:  Seale 


e.sot29.7cm  Paqeiofl  izoit 


“iAct  ' '  1 

f//  4 

i  Battle  rr? 

i  ausLio 

iin 

S  I  H 

security 


Session  Display  Area 


Object  Management  -J  | 


Battlemap  —  DefauR 


Figure  2:  Remote  execution  demonstration  from  AUSTACSS 


All  of  the  attempted  JCSE  applications  (Applix  word,  Picture  Manager, 
Message  Queue  Manager,  Lotus  Notes),  were  able  to  be  run  from  AUSTACSS. 
It  was  possible  to  cut  bitmaps  from  both  Mapping  packages  and  paste  them 
into  an  Applix  document.  It  was  possible  to  cut  text  from  an  AUSTACSS 
message  and  paste  it  into  a  Lotus  Notes  email,  and  transmit  the  information 
to  other  JCSE  users.  However,  several  problems  were  experienced  during  the 
modification  and  testing  of  these  features. 
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2.3.1  Problems  with  Colours  in  AUSTACSS 

There  were  several  problems  with  colourmaps  during  the  investigation.  The 
JCSE  Picture  Manager  attempts  to  define  the  colour  "black"  at  startup  and 
fails,  so  the  background  is  displayed  as  white  instead  of  black.  This  is 
unacceptable  because  when  a  Picture  Manager  track  is  selected,  it  is  displayed 
in  white  and  thus  cannot  be  seen  against  the  white  background. 

2.3.2  Problems  with  Resources  in  AUSTACSS 

Because  the  software  was  running  remotely,  all  information  to  be  displayed 
had  to  be  transmitted  over  the  network.  That  tended  to  slow  down  the 
response  time  (performance  results  are  presented  in  Section  2.6).  In  addition, 
the  processing  power  and  memory  of  the  remote  computer  was  being 
utilised.  Both  JCSE  and  AUSTACSS  have  stringent  memory  requirements 
associated  with  the  mapping  packages.  This  situation  was  complicated  by  the 
fact  that  when  a  user  exited  a  remote  program,  the  display  connection  was 
terminated.  On  some  occasions  the  display  connection  was  terminated  before 
the  remote  program  had  time  to  shut  down  completely.  If  this  process  of 
running  and  exiting  the  remote  mapping  package  was  repeated,  the  remote 
workstation  soon  ran  out  of  swap  space  and  was  unable  to  restart  the 
mapping  package.  This  situation  can  be  resolved  by  terminating  some  of  the 
unwanted  processes,  which  could  be  automated  in  a  script  for  future 
demonstrations. 


2.4  Results  of  JCSE  to  AUSTACSS  remote  execution 


Figure  3  depicts  an  example  session  where  a  JCSE  user  has  access  to  both  the 
AUSTACSS  Battlemap  and  the  JCSE  Picture  Manager. 
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Battlem«4):  Default 

Background:  Default 

Active  Overlay:  OvNiayi 


Session  DispiayArea  Display  Features  O^bjeet  D[splay  Options  Deeisio 
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133704S  1063708E 
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Options  Query  ^LCkgrotsid  ^erlay 


Figure  3:  Remote  execution  demonstration  from  JCSE 

All  of  the  attempted  AUSTACSS  applications  (Applix  word,  Battlemap, 
Message  History,  Filer),  were  able  to  be  run  from  JCSE.  There  were  however, 
some  additional  problems.  One  of  the  features  of  AUSTACSS  is  that  the 
messaging  application  is  tightly  integrated  with  Applix  word,  the  Filer 
application  and  the  Database.  For  example,  to  send  a  message  in  AUSTACSS, 
the  user  normally  writes  the  message  text  in  an  Applix  Word  document, 
drags  and  drops  the  file  icon  for  the  document  on  the  Mail  icon.  The 
messaging  application  is  then  automatically  invoked.  This  presents  a 
problem  for  the  remote  execution  approach,  because  several  aspects  of  the 
CDE  functionality  have  been  customised  in  AUSTACSS,  but  the 
customisation  is  not  available  in  JCSE.  For  example,  although  the  AUSTACSS 
Filer  application  can  be  seen  from  JCSE,  and  the  directory  structure  can  be 
viewed  and  traversed,  if  the  user  double  clicks  on  a  document  in  the  filer, 
Applix  Word  will  not  be  invoked  to  edit  the  document.  In  fact,  the  Filer  will 
disappear  because  an  error  has  occurred.  This  problem  may  be  able  to  be 
rectified  by  further  modifying  the  AUSTACSS  scripts  to  recognise  that  a 
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remote  request  has  been  received.  This  example  highlights  some  limitations 
of  the  remote  execution  approach. 


2.5  Problems  with  the  Remote  Execution  Approach 


In  addition  to  the  problems  presented  in  Section  2.3  and  2.4,  there  are 
potential  software  engineering  difficulties.  At  this  point  the  Demonstrator 
illustrates  potential  capability.  However,  implementing  it  in  an  operational 
system  will  present  difficulties  in  the  areas  of  configuration  management  and 
ongoing  maintenance.  First  of  all,  staff  will  need  training  in  both  systems. 
Second,  there  are  problems  resulting  from  the  dependencies  between  the  two 
systems.  For  example,  systems  are  sometimes  upgraded  to  a  new  release. 
This  may  cause  a  failure  when  the  older  system  on  the  other  end  attempts  to 
run  it  remotely. 

Therefore,  remote  execution  should  be  seen  only  as  a  stop-gap  measure  while 
trying  to  provide  for  the  user's  real  requirement:  access  to  one  integrated 
system.  Another  consequence  of  this  capability  is  that  users  may  require 
training  on  both  systems. 

2.6  Performance  Results  for  the  Remote  Execution  Approach 


Table  1:  Performance  Comparison  for  Remote  Execution 


Operation 

JCSE 

Remote 

Execution 

0/ 

/o 

Increase 

Start  Picture  Manager 

1:56 

1:54 

-1.7 

Zoom  in  Picture  Manager 

0:09 

0:06 

-33.3 

Page  down  in  JCSE  Word 

0:06 

0:09 

50.0 

AUSTACSS 

Start  Battlemap 

0:42 

0:52 

20.0 

Zoom  in  Battlemap 

0:05 

0:08 

60.0 

Page  down  in  AUSTACSS  Word 

0:08 

0:11 

37.5 

Table  1.  shows  the  relative  performance  of  remote  and  local  execution  of 
several  applications.  As  shown,  remote  execution  is  not  significantly  slower 
than  when  logged  in  directly,  and  the  performance  of  some  JCSE  applications 
unexpectedly  improved  when  run  remotely. 

When  Table  1  is  compared  with  the  performance  results  presented  in 
Section  3  below,  it  would  appear  that 

•  JCSE  is  under  high  CPU  utilisation  during  these  activities  and  some  of  the 
processing  is  unloaded  to  the  remote  machine  during  remote  execution. 
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•  Although  the  CPU  utilisation  is  high,  it  is  not  100%  as  in  the  case  of  AUSTACSS, 
so  it  may  be  that  the  JCSE  workstation  is  spending  a  lot  of  time  swapping  data 
between  memory  and  disk.  Having  the  information  displayed  remotely  may 
reduce  this  memory  swapping  and  further  increase  performance. 

•  On  the  surface,  it  would  appear  that  the  AUSTACSS  workstation  is  faster  than  the 
JCSE  workstation,  which  would  also  increase  the  display  speed  when  a  JCSE 
application  is  being  displayed  on  an  AUSTACSS  workstation. 

It  should  be  noted  that  these  performance  measurements  were  taken  for  a 
specific  system  configuration.  In  particular,  the  CCISIL  was  set  up  with  a 
small  number  of  workstations  on  a  dedicated  LAN  which  thus  has  a  very  low 
level  of  network  traffic.  As  network  traffic  increases,  a  corresponding 
decrease  in  performance  would  be  expected. 

These  figures  are  not  intended  to  make  comparisons  between  AUSTACSS  and 
JCSE,  and  should  not  be  used  to  do  so.  There  are  many  variables  such  as  the 
level  of  map  detail,  and  performance  of  the  hardware  installed  in  the  CCISIL 
which  make  such  a  comparison  meaningless. 
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3.  PC  X  Emulation  Software 


Defence  already  operates  a  number  of  PC  based  LANs.  FEPCIS  is  an  example  of 
such  a  network.  The  combination  of  those  LANs  and  the  new  availability  of  high 
quality  X  emulation  software  packages,  makes  it  possible  to  offer  a  low  cost  platform 
to  access  AUSTACSS  or  JCSE.  Some  users  may  see  this  as  a  value-add  to  their 
existing  capabilities. 

The  Strategic  Client  Demonstrator  project  investigated  the  ability  of  several  X 
emulation  packages  to  log  into  and  run  JCSE  and  AUSTACSS. 


3.1  CCISIL  Setup  and  Methodology 


For  this  investigation,  the  CCISIL  was  set  up  as  shown  in  Figure  4 


Figure  4:  CCISIL  Setup  for  X  emulation  investigation 


A  Windows  95  based  PC  was  connected  to  the  same  LAN  as  the  two  C3I  systems. 
Three  separate  PC  X  emulation  packages  were  evaluated: 

•  Xwin32  version  3.2.8  by  StarNet  Communications  corp. 

•  eXodus  version  5.6.4  by  White  Pine  software. 
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•  eXceed  version  5.1.1  by  Hummingbird. 

The  PC  was  configured  with  32  Megabytes  of  RAM  and  a  Pentium  processor.  The 
screen  was  set  to  the  1280  by  1024  mode  so  that  when  the  PC  was  logged  into  a 
UNIX  system,  the  display  looked  identical  to  the  local  UNIX  display. 

An  attempt  was  made  to  login  to  JCSE  and  AUSTACSS  from  the  PC  and  run  the  CIS, 
messaging  and  Office  Automation  software. 

3.1.1  PC  X  Emulation  Performance  Test 

The  response  times  of  JCSE  and  AUSTACSS  were  measured  for  various  tasks,  to  get 
an  indication  of  achievable  performance  using  PC  X  emulation.  These  tasks  include: 

•  Log  in  to  the  system  from  the  CDE  /  HP  VUE 

•  Start  the  mapping  package 

•  Zoom  in  to  Tasmania  from  Australia  in  the  mapping  package 

•  Page  down  in  a  test  document  in  Applix  Word 

The  times  were  measured  using  a  stopwatch. 

3.1.2  CPU  Utilisation  Test 

A  test  was  conducted  on  both  AUSTACSS  and  JCSE,  to  determine  the  level  of  CPU 
usage  while  a  user  was  logged  in  from  the  PC.  For  this  test  the  eXodus  X  emulation 
package  was  used.  The  CPU  utilisation  was  recorded  using  the  vmstat  command, 
which  in  this  case  wrote  the  average  CPU  usage  every  5  seconds.  This  test  was 
intended  to  be  representative  of  a  high  usage  period  by  the  PC  user  while  no  other 
activity  was  occurring  in  the  system.  The  basic  sequence  of  events  are  as  follows: 

•  Log  into  system  from  DCE/HP  VUE  screen 

•  Start  the  mapping  application 

•  Zoom  into  Tasmania  from  a  view  of  Australia 

•  Start  Applix  Word 

•  Open  the  test  document  (which  contains  several  large  bitmaps  and  pages  of  text). 

•  Page  down  through  the  test  document 

The  timings  for  each  of  these  activities  are  given  in  the  results  section  so  that  they 
can  be  compared  with  the  peaks  on  the  CPU  utilisation  graphs.  Note  that  the  PC 
was  logged  into  the  JCSE  or  AUSTACSS  server  for  these  measurements. 

3.2  Results  for  PC  X  emulation 

Both  JCSE  and  AUSTACSS  were  able  to  be  run  remotely  from  a  PC.  Apart  from 
performance,  the  look  and  feel  of  the  C3I  systems  was  identical  to  the  normal 
workstation  displays.  The  performance  in  both  cases  was  noteably  slower  than  that 
experienced  when  logging  in  directly  to  the  workstation.  The  Xwin32  software  was 
unable  to  log  into  the  AUSTACSS  system.  The  reasons  for  this  are  unknown  and 
thought  to  be  the  result  of  errors  in  the  Xwin32  software.  It  was  noted,  however. 
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that  the  Xwin32  package  could  log  into  another  computer  running  the  Solaris  2.5 
operating  system. 

The  JCSE  Picture  Manager  provided  a  challenge  for  the  X  emulation  packages.  This 
is  because  the  Picture  Manager  software  writes  track  symbols  and  other  graphics  to 
the  screen  on  top  of  mapping  graphics  drawn  by  the  Genasys  software.  Picture 
Manager  relies  on  the  X  server  to  store  a  copy  of  the  display  under  such  symbols  and 
restore  them  when  required.  The  Xwin32  software  does  not  appear  to  provide  this 
capability,  and  the  eXceed  package  needed  to  be  re-configured  in  order  to  support 
this.  If  the  display  underneath  is  not  stored,  as  with  Xwin32,  the  resulting  display 
has  large  areas  of  random  colour. 


3.3  Performance  Results  for  PC  X  emulation 


Table  2.  Provides  a  comparison  of  the  performance  of  each  of  the  X  emulation 
packages,  with  that  experienced  when  logged  into  the  workstation. 

Table  2:  Performance  comparison  for  X  emulation  packages 


Operation 

JCSE 

Xwin32 

eXodus 

eXceed 

Average  % 
Increase 

Log  in  to  JCSE 

0:40 

1:14 

0:46 

0:57 

47.5 

Start  Picture  Manager 

1:56 

2:02 

1:58 

1:58 

28.7 

Zoom  in  Picture  Manager 

0:09 

0:15 

0:19 

0:16 

85.2 

Scroll  down  in  JCSE  Word 

0:06 

NA 

0:10 

0:11 

75.0 

AUST¬ 

ACSS 

Log  in  to  AUSTACSS 

0:36 

NA 

0:44 

0:56 

38.8 

Start  Battlemap 

0:42 

NA 

0:52 

0:52 

23.8 

Zoom  in  Battlemap 

0:05 

NA 

0:11 

0:10 

110.0 

Scroll  down  in  AUSTACSS  Word 

0:08 

NA 

0:12 

0:11 

43.8 

Although  the  response  time  is  significantly  slower,  particularly  for  zooming  in  the 
mapping  packages,  it  is  thought  to  be  reasonable.  As  in  the  case  of  remote 
execution,  these  performance  figures  were  obtained  with  a  lightly  loaded  network. 
Network  traffic  will  effect  the  response  time. 
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Figure  7  and  Table  3  describe  the  CPU  utilisation  test  results  for  AUSTACSS,  while 
Figure  8  and  Table  4  describe  those  for  JCSE.  It  can  be  seen  that  the  periods  of 
highest  activity  for  both  systems  is  during  login  and  starting  the  mapping  packages. 
Note  that  the  AUSTACSS  system  reaches  full  CPU  utilisation  several  times  during 
the  test. 


AUSTACSS  CPU  USAGE 


Time  (seconds) 


Figure  5:  %  CPU  Usage  X  emulation  of  AUSTACSS  (eXodus) 


Table  3:  Actions  completed  during  AUSTACSS  CPU  utilisation  test 


Action 

Relative  start 
(seconds) 

Login 

20 

Start  BattleMap 

80 

Zoom  in  BattleMap 

125 

Start  Applix  Word 

145 

Open  test  file 

180 

Page  to  bottom  of  test  file 

215 

Finish 

245 
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The  JCSE  system  does  not  reach  full  CPU  utilisation  during  this  test,  indicating  that 
system  may  be  slowed  down  by  a  lack  of  real  memory,  disk  speed,  network 
bandwidth  or  the  time  the  PC  is  taking  to  display  the  information. 


Time  (Seconds) 


Figure  6:  %  CPU  Usage  X  emulation  of  JCSE  (eXodus) 
Table  4:  Actions  completed  during  JCSE  CPU  utilisation  test 


Action 

Relative  start 
(seconds) 

Login 

39 

Start  Picture  Manager 

80 

Zoom  in  Picture  Manager 

165 

Start  Applix  Word 

190 

Open  test  file 

240 

Page  to  bottom  of  test  file 

263 

Finish 

279 

These  results  indicate  that  there  is  some  room  for  more  than  one  PC  to  run  off  a 
single  workstation  or  server,  particularly  as  the  measurements  were  taken  during  a 
period  of  high  activity.  Clearly  if  many  PCs  were  to  be  run  from  a  single  server,  a 
high  powered  CPU  and  more  memory  would  be  required. 
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4.  Conclusions 


This  report  has  described  the  demonstration  of  several  potentially  useful 
concepts  in  the  CCISIL,  which  go  some  way  toward  addressing  the  problem 
of  ADF  staff  requiring  access  to  more  than  one  system.  A  new  capability  has 
been  demonstrated  to  achieve  a  moderate  level  of  integration  between 
AUSTACSS  and  JCSE  for  sites  that  are  running  both  systems.  This  work  has 
revealed  the  problems  that  can  occur  as  a  result  of  using  remote  execution, 
particularly  for  applications  with  high  levels  of  customisation  or  integration 
as  is  the  case  for  the  current  build  of  AUSTACSS. 

An  ability  to  use  either  AUSTACSS  or  JCSE  from  a  commercial  PC  X 
emulation  package  has  been  demonstrated.  Performance  measurements 
indicate  that  both  remote  execution  and  PC  emulation  provide  reasonable 
response  times,  provided  that  the  network  is  not  overloaded.  Further,  an 
analysis  of  the  CPU  utilisation  of  the  host  during  a  high  activity  period  would 
indicate  that  there  is  potential  for  several  PCs  to  run  off  a  server,  and  possibly 
more  from  a  suitably  configured  server. 
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